REMARKS 

In the Office Action dated September 4, 2009, claims 2-6 were rejected under 35 U.S. C. 
§ 103(a) as obvious over U.S. Patent Publication No. 2003/0172177 to Kersley et al. ("Kersley") 
in view of U.S. Patent Publication No. 2002/0190356 to Buechler et al. ("Buechler") as 
evidenced by English, ADA 95: The Craft of Object-Oriented Programming, "Glossary" 
("English"). Applicants respectfully traverse the rejections for the reasons set forth below. 

A. Claims 2-6 Are Not Obvious Over Kersley, Buechler and English 

Applicants have invented a device verification method which provides a single flag for each 
of a plurality of packet classes so that when a packet from a packet class is generated, that packet is 
used to test the device for that packet class only if the flag for that packet class is in a first state (e.g., 
"0" to indicate that the packet class has not been tested), at which point the flag is changed to the 
second state (e.g., "1" to indicate that the packet class has been tested). See, claim 2. In this way, a 
device is tested by packet class since a packet within each packet class will only be used to test 
the device if the flag for that packet class has not been set to the second state. With Applicants' 
approach, packets need not be stored in memory, but can instead be "generated" as claimed (e.g., 
randomly), and each generated packet in a given packet class can be checked against the flag for that 
packet class to determine if the packet will be used to test the device. In this way, the present 
invention eliminates the costs associated with storing all possible packets to be tested, and also 
eliminates the inefficient testing of devices with redundant packets by using a single flag for each 
packet class to determine if a generated packet in the packet class will be used to test the device. 

In rejecting claims 2-6 as obvious over Kersley, Buechler and English, the Examiner 
asserts that Kersley' s disclosed method for verification of a device-under-test (Kersley, Fig. 2, "[flf 
5-7, 18, 21-22, 35, and 43) meet the claim requirements except for variously recited requirements 
of (1) "providing a flag, which may be of a first or a second state, for each of the plurality of 
packet classes" (claims 2-6); (2) testing the device "if the flag of the packet class of the 
generated packet is in the first state" (claims 2-3 and 5-6); (3) not testing the device "if the flag 
of the packet class of the generated packet is in the second state" (claims 3-6); and (4) "changing 
the flag of the packet class of the generated packet to the second state" "if the flag of the packet 
class of the generated packet is in the first state" (claims 2 and 5-6). See, Office Action , pp. 2-6. 
To overcome these deficiencies in Kersley' s disclosure, the Examiner cites Buechler' s disclosure 
(Buechler, ]f 78) of using "record flags" to assure that all required assay tests are performed and 
to avoid duplication of testing. Id., pp. 6-8. 
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In reply, Applicants respectfully submit that a prima facie case of obviousness has not 
been established for claims 2-6 because the Examiner has not met the burden of showing that all 
the claim limitations are taught or suggested by the prior art. To establish a prima facie case of 
obviousness, the Examiner has the burden of showing that all the claim limitations are taught or 
suggested by the prior art. In re Rovka , 490 F.2d 981, 180 USPQ 580 (CCPA 1974); In re 
Wilson , 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). To make this showing of 
obviousness, three basic criteria must be met. First, there must be some suggestion or 
motivation, either in the reference itself or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference as proposed by the Examiner. Second, there 
must be a reasonable expectation of success. Finally, the prior art reference must teach or 
suggest all the claim limitations. The teaching or suggestion to modify the reference and the 
reasonable expectation of success must both be found in the prior art, not in Applicants' 
disclosure. MPEP §§ 2143.01-03. 

In this case, the rejection analysis appears to have mischaracterized the claimed invention 
by ignoring the requirement that a single flag be used for each packet class to determine: 

(1) whether the device is tested with the generated packet (as variously required in claims 
2-3 and 5-6 which require device testing "if the flag of the packet class of the generated 
packet is in the first state"); 

(2) whether the device is not tested with the generated packet (as variously required in 
claims 3-6 which require no device testing "if the flag of the packet class of the generated 
packet is in the second state"); and/or 

(3) whether the flag is changed to a second state (as variously required in claims 2 and 5- 
6 which require changing the flag state if the flag of the packet class of the generated 
packet is in the first state"). 

In short, Applicants have disclosed and claimed using a single flag for each packet class to drive 

and determine these various actions (test, not test, change flag state). The Examiner has 

conceded that Kersley does not meet these flag-based requirements ( Office Action , pp 5-6), and 

indeed there would be no such need suggested or allowed since Kersley teaches using a "packet 

database 142" to store "standard and/or custom headers, optional trailers as well as predefined 

payload data." See, Kersley, \ 63. 

The attempted reliance on Buechler to remedy the deficiencies in Kersley's disclosure is 

also misplaced since Belcher explicitly discloses using a plurality of record flags to track tests 

and prevent duplication. See, Buechler, U 78 ("In order to assure that all required tests are 
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performed, and also to avoid duplication of testing, record flags or other techniques can be used 
when the database 464 is accessed to retrieve test instructions. For example, when fluorometer 
100 accesses information system 408 to receive instructions for a particular test, that test is 
flagged as being performed such that subsequent accesses by this or another fluorometer 100 will 
not retrieve the same test instructions. Once a test is completed and the results provided to 
information system 408, another flag can be set indicating the status of the test as being 
completed.") (emphasis added). Thus, Buechler teaches using a "record flags " such that a first 
flag is set (when "fluorometer 100 accesses information system 408 to receive instructions for a 
particular test") and "another flag" is set (when the test is completed). Rather than meeting the 
variously recited requirements in claims 2-3 and 5-6 of testing the device "if the flag of the 
packet class of the generated packet is in the first state," Buechler discloses accessing the test 
instructions without first checking the state of an associated flag for the test. Likewise, rather 
than meeting the variously recited requirements in claims 3-6 of not testing the device "if the flag 
of the packet class of the generated packet is in the second state," Buechler discloses accessing 
"another flag" (not the same flag) to see if the test has been completed. Finally, rather than 
meeting the variously recited requirements in claims 2 and 5-6 of changing the flag to the second 
state "if the flag of the packet class of the generated packet is in the first state," Buechler 
discloses setting "another flag can be set" (not the same flag) "[o]nce a test is completed and the 
results provided to information system 408." In sum, Buechler uses two flags, not one flag as 
claimed, and sets the flags in response to different triggers than claimed. Buechler's use of 
multiple flags for each test should come as no surprise since Buechler's fluorometer testing 
scheme is concerned with only a limited number of tests, so there would be no significant 
penalty in tracking multiple flags for each test. In contrast, Applicants' disclosed verification 
scheme is being used to test devices with "several thousand different combinations" of possible 
packet classes being tested. See, Application , p. 1, lines 20-21 . 

Another problem with the cited art is that neither Kersley nor Buechler disclose or suggest 
"providing a plurality of packet classes ." much less "providing a flag ... for each of the plurality of 
packet classes " as recited in each of the pending claims. On this point, Applicants have carefully 
review the cited disclosure from Kersley (Fig. 2, 5-7, 18, 21-22, 35, 43), but there is absolutely no 
teaching or suggestion of any "packet class" test pattern, much less of providing a flag for each 
"packet class." Even if one (improperly) assumes that English's "flag" would be combined with 
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Kersley's system for generating and testing packets, there is simply no teaching or suggestion that 

Kersley's packet testing methodology provides "a plurality of packet classes," much less that any of 

English's flags would be provided "for each of the plurality of packet classes," as recited in the 

claims. Instead of being concerned with testing by packet class, Kersley is concerned with verifying 

a device-under-test by "generating packets to simulate complex network packet traffic patterns to test 

and verify a device under test (DUT)." Kersley, paragraph 5. 

In addition to the missing claim requirements, Applicants submit that a person having 

ordinary skill in the art would not have combined the Kersley and Buechler references in the first 

place. On this point, the Examiner asserts that: 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
modify/combine the features of Kersley by using the above-recited features, as taught by 
Beuchler, in order to provide a method s preventing duplication of testing, thus decreasing 
wasteful testing time and additional resources used by not performing tests that already have 
been performed (see Beuchler sections 0078). One could have implemented the teaching of 
Beuchler to the concept of test packets of Kersley, where flags are kept for the different. 

Office Action , p. 8 (emphasis added). While this quote is not entirely clear, the Examiner appears 

to be arguing that the "record flags" described by Beuchler "could" have been used with 

Kersley's packet-based verification system. But the proper legal standard is not what could a 

person having ordinary skill in the art do. Instead, the question is what would such a person do. 

And in this case, the Examiner has failed to show how a person skilled in the art would be 

motivated to combine the references. See, DyStar Textilfarben GMBH v. C. H. Patrick Co. , 464 

F.3d 1356, 80 USPQ2d 1641 (Fed. Cir. 2006) ("'[CJonclusory statements such as those here 

provided do not fulfill the agency's obligation' to explain all material facts relating to a 

motivation to combine."). As required by the recent KSR decision, the Examiner must provide 

"some articulated reasoning with some rationale underpinning to support the legal conclusion of 

obviousness" and must "identify a reason that would have prompted a person of ordinary skill in 

the relevant field to combine the elements in the way the claimed new invention does." KSR v. 

Teleflex . 127 S. Ct. 1727, 82 U.S.P.Q.2d 1385 (2007). In addition, the Examiner must make 

"explicit" this rationale of "the apparent reason to combine the known elements in the fashion 

claimed," including a detailed explanation of "the effects of demands known to the design 

community or present in the marketplace" and "the background knowledge possessed by a 

person having ordinary skill in the art." Id. Anything less than such an explicit analysis does not 

meet the requirement of a prima facie case of obviousness. 
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Applicants respectfully submit that inclusion of Beuchler's "record flags" with Kersley's 
verification system would not be made by a person having ordinary skill in the art. To add a flag 
storage requirement to Kersley's system which uses a "packet database 142" to store and 
generate packets as proposed by the Examiner would actually increase the requirements for 
storing and processing the flag information, and "record flags" would be unnecessary if the 
"packet database 142" already stores the packets. In other words, the proposed combination is 
improper because it would change the principle of operation of Kersley's system by addition 
additional and superfluous requirements for storing and processing record flags. See, MPEP § 
2 143. 01 (VI) ("If the proposed modification or combination of the prior art would change the 
principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious.") (citing In re Ratti , 123 
USPQ 349 (CCPA 1959)). 

In the absence of a prima facie showing that the requirements of claims 2-6 are disclosed in 
or obvious over the prior art, or that the cited references would be combined in the first place, 
Applicants request that the obviousness rejection of claims 2-6 be withdrawn and that the claims be 
allowed. 

CONCLUSION 

In view of the remarks set forth herein, Applicants respectfully submit that all pending 
claims are in condition for allowance. Accordingly, Applicants request that a Notice of 
Allowance be issued. Nonetheless, should any issues remain that might be subject to resolution 
through a telephone interview, the Examiner is requested to telephone the undersigned at 512- 
338-9100. 
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